IBIS Macromodel Task Group Meeting date: 07 November 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad asked if we should consider cancelling next week's meeting because of the IBIS Summits in Asia. Bob noted that he thought Mike LaBonte was the only regular attendee who would be at the Summits. Arpad decided we should hold next week's ATM meeting as usual. ------------- Review of ARs: - Bob and Radek to produce a new draft of BIRD189.5 containing the two-column format for Unused_port_terminations. - Done. - Discussion: Arpad noted that this had been done, but he asked if it had been rolled into a new draft. Bob noted that at a subsequent meeting (Interconnect meeting last Friday) a vote had been taken to roll back the two column solution and get rid of per port impedance. Radek said it had been voted out without further technical discussions, and that he felt we should discuss it in the ATM meeting since it had been discussed here too. Arpad said we could continue to discuss it in ATM. Walter suggested that the decision had been made in the Interconnect meeting, that there was no reason to discuss it further here, and that it could be taken off the ATM agenda. Walter suggested someone could reopen the discussion in the future if they wanted to do so. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Radek: Motion to approve the minutes. - Walter: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD165.1: - Arpad: [sharing BIRD165.1 draft 1] - BIRD165 was introduced in 2014. - I've made significant changes to the "Statement of the Issue" section, but these are non-technical improvements in the wording. - The "Any Other Background Information" section lists the changes made to create this draft. It also defines the color scheme: - green - differences between this and the IBIS spec. - change tracking (in red) indicates differences between this draft and the original BIRD165. - Original BIRD165 was written relative to IBIS 6.0. This version updates the page number references relative to IBIS 6.1. The text being changed is no different in 6.1 than it was in 6.0. - [Circuit Call] keyword section is modified. It gets text duplicating the parameter passing stuff from [External Circuit]. - Parameters and Converter_Parameters are added as Sub-Params. - New (duplicated) sections describe what they do. - Rules for using them are the same as for [External Circuit], except that if they exist in [Circuit Call] then they override any values in the [External Circuit]. - Only other change is the modification of the Figure 29 example to include an example of the use of Parameters (change on pg. 134) in [Circuit Call]. - Walter asked me the purpose of the Parameter "C1_value" that has nothing following it. - This is what we had before parameterization was added in in 6.0. This is the old syntax, where the value wasn't given and it was presumed the tool would allow the user to enter values for the parameters. Having it in the example just shows this old syntax is still available, though it doesn't seem very useful. - Radek: My only issue is the "C1_value" example Walter brought up, but I understand your explanation. - The logic behind this proposal is good. It's good to differentiate between different instantiations. - I'm not sure the "will be in effect" (override) is necessary or not, but when you instantiate a subcircuit you don't have to specify values for all the parameters in the subcircuit. - Arpad: With regard to the "C1_value" example: - I agree with you and Walter that this doesn't make a lot of sense. - But this was the only thing we had before IBIS 6.0. The idea was that listing the parameter names would allow the tool to create some GUI listing the parameters so the user could provide values. - The reason we added parameter values is that the IBIS file was at least a place to consolidate and maintain all the values, so the user didn't have to look up values from all different sources (data sheets, etc.). - I wondered if we should deprecate that old syntax, but that makes things more complicated. I felt it was simplest to leave the old syntax, add the new syntax, and assume people won't use the old syntax if it's not useful. - Walter: I can conceive of one reason for the old way. - You may have a subcircuit which has a parameter, but the subcircuit declaration has a default value. - The old syntax might be a way to let the user know the parameter exists, but the default value in the subcircuit should be used. - Bob: We should just keep the old syntax. If nobody uses it that's fine. - Arpad: Agreed. - I will get this draft to Mike for posting to the ATM archives. BIRD189 - File_TS0 restrictions. - Arpad: [sharing Radek's email to ATM from earlier in the day] - Radek: We started discussing this topic at the Friday Interconnect meeting. - This is a serious issue. The File_TS0 was added for convenience, but it hasn't been completely thought out. - BIRD189 allows IBIS-ISS or Touchstone data. - For Touchstone data, the Sub-param was File_TS. - For File_TS, the Number_of_terminals must be N+1. N ports are defined between terminals 1 through N and the N+1 reference terminal. - IBIS-ISS, and HSPICE and others allow other forms of S-element component that may have N, N+1, or 2N terminals. - The N and N+1 forms differ only in what the N+1 terminal is. When only N terminals are specified, it's implicit that the N+1 terminal is global node 0. That's the only difference. The user could take an N+1 version and connect the N+1 terminal to node 0 and get the same thing. - Now we've introduced the File_TS0 (N terminals). - What are the consequences of that? Connectivity. - The problem is that the implicit node 0 is not required to be present throughout the entire span of the interconnect modeling. - We have a type of modeling with a number of nodes, which are spanned by the interconnect models, and then suddenly we could have a component (File_TS0) which is implicitly connected to a completely different node outside the set of nodes in the modeled area. - So this draft is fundamentally flawed. - The only way this might work in its current form, if we want to keep it, is the requirement that the data inside the Touchstone file supports the possibility of that terminal being connected to anything. That really means that no current is flowing through that implicit terminal into the internal part of the component. - I added a statement of this requirement for the Touchstone file used in a File_TS0 in the third paragraph of my email: If the same Touchstone file is used for an S-element with N+1 nodes, then for any loading conditions (the external circuitry outside of the S-element) and at all frequencies present in the file the current entering (or leaving) the N+1st node is zero. - That's the general requirement. This is equivalent to saying that N+1st terminal of the component is isolated from the rest of the component internally. - We don't have that requirement in the current draft. I'm not sure the parser is capable of checking for it. If the data is not restricted, we have a problem knowing what any EDA tools will do with it. - Arpad: The original idea behind adding File_TS0 was addressing the case in which there are no pins under the [Pin] keyword that are suitable as a reference terminal. - We discussed the option of using node 0 in that case, and I suggested the A_gnd syntax to specify that, but people didn't like that. - We couldn't come up with a way of specifying node 0 that everyone liked, so the idea of using the special File_TS0 and stating in the rules that it is implicitly connected to node 0 was proposed. - Isn't it always true that the sum of the currents has to be zero, even if this reference node were connected to a pin on the [Pin] list? - Wouldn't your restriction be true for File_TS, too? - Radek: No, in the File_TS case, the N+1st terminal is one of the accessible terminals connected in the model. - If you had the N+1 version (File_TS) and didn't connect the N+1st terminal to anything, then you'd have a problem. But the model maker uses all N+1st terminals. - In fact, to address this problem we need to explicitly state that for File_TS the N+1st terminal is not allowed to be one of the unspecified ones. - There are consequences to the requirement (specified above for TS0) that the N+1st terminal is isolated internally from the rest of the terminals in that S-element. There are very strict and necessary conditions that lead to the statement I made about the restrictions. - The fact that the terminal is isolated leads to the non-existence of the Z matrix, which in turn implies the singularity of the Y matrix. - Most of the Touchstone files that are out there do not actually meet this restriction, but that's only a necessary condition. - Bob: I disagree with the statement that no current would flow through node 0. - Consider a one port case. Current could flow into terminal 1 and out through the implicit reference node (node 0). - Radek: You disagree with something completely different. You disagree that the Touchstone data for a one port would result in no current flowing if you connect it to node zero. But if you connect it to a different node, or change the topology so a different node is your node 0, you get completely different results. - Discussion: Radek said that if File_TS0 involved an implicit connection to a node that might not be available to the rest of the interconnect models, then the only way to avoid ambiguity and be certain of the results would be the "no current flowing through the reference terminal" (reference terminal internally isolated) restriction. Bob thought the other interconnect models would have access to the same implicit reference node if necessary. Bob said that he would support adding text explaining that File_TS and File_TS0 models could not be intermingled without risking dire consequences. Radek said another possible solution was to explicitly add the N+1 terminal in the File_TS0 case, so that whatever reference it was connected to was made available to the rest of the interconnect models. Bob noted that BIRD158 models assumed a File_TS0 style common reference. Radek agreed that in BIRD158 the implied N+1st node is the implicit reference that's used for the entire channel. Arpad asked Randy about his experience developing S-parameters for on-die decap models. Randy said they had tried some one-port modeling approaches, but generally had better correlation results using a two port model with a reference to zero. Bob noted that the spec already contains a statement about possible issues with power-aware simulations using global node 0. He suggested that we add more specific guidance about possible issues mixing File_TS and File_TS0. Bob noted that example 4 in BIRD189.5-draft10 actually contains a mix of File_TS and File_TS0, and he suggested that the example should be fixed because model makers should not do that. Walter said he thought model makers knew enough not to create model configurations that wouldn't work, and that we needn't spell out any more rules for them. Bob said that if we couldn't spell out the rules, how could a model maker be expected to do things correctly? Arpad again asked what we would do in the case when no pin in the [Pin] list could serve as the reference, and he again noted that File_TS0 was created for this situation. He said there should be no need for mixed use of File_TS and File_TS0, because if a suitable reference pin existed it would be available to all of the Touchstone models. Bob noted that this was not the only reason for File_TS0, and he and Walter noted that many model makers distribute Touchstone models based on the implicit node 0. - Walter: Motion to adjourn. - Bob: Second. - Arpad: Thank you all for joining. AR: Arpad to send the draft of BIRD165.1 to Mike L. for posting to the ATM archives. ------------- Next meeting: 14 November 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives